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Transmitting IP Traffic over ARCNET Networks 
Status of this Memo 


This memo defines a protocol for the transmission of IP and ARP 
packets over the ARCnet Local Area Network. This RFC specifies an 
TAB standards track protocol for the Internet community, and requests 
discussion and suggestions for improvements. Please refer to the 
current edition of the "IAB Official Protocol Standards" for the 
standardization state and status of this protocol. Distribution of 
this memo is unlimited. 


1. Introduction 


This memo specifies a method of encapsulating Internet Protocol (IP) 
[1] and Address Resolution Protocol (ARP) [2] datagrams for 
transmission across ARCNET [3] using the "ARCNET Packet Header 
Definition Standard" [4]. This memo offers a replacement for RFC 
1051. RFC 1051 uses an ARCNET framing protocol which limits 
unfragmented IP packets to 508 octets [5]. 


2. ARCNET Packet Format 


In 1989, Apple Computers, Novell, ACTINET Systems, Standard 
Microsystems, and Pure Data Research agreed to use the ARCNET 
datalink protocol defined in "ARCNET Packet Header Definition 
Standard" [4]. We’ll begin with a brief description of that 
protocol. 


2.1. ARCNET Framing 


ARCNET hardware supports two types of frames: short frames, which are 
always 256 octets long, and long frames, which are always 512 octets 
long. All frames begin with a hardware header and end with the 
client’s data preceded by a software header. Software places padding 
in the middle of the packet between the hardware header and the 
software header to make the frame the appropriate fixed length. 
Unbeknown to the software, the hardware removes this padding during 
transmission. 


Short frames can hold from 0 to 249 octets of client data. Long 


frames can hold from 253 to 504 octets of client data. To handle 
frames with 250, 251, or 252 octets of data, the datalink protocol 
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introduces a third frame type: the exception frame. 


These three frame formats are shown here. Except as noted, each 
block represents one octet. 


Short Frame Long Frame Exception Frame 
ss aoa ia tat at gta se + tose SSse > naase + fon onneen + 
| source | | source | | source | 
toa sas + prantan + þanni + 
| destination | | destination | | destination | 
EE + palna + ponei + 
| offset | | 0 | | 0 | 
Teo eeann n nea + teasg neante n + saa + 
unused ; | offset | | offset | 
(Offset = 3 4 T N T + O SSeS Se + 
$ octets) š . unused . $ unused 
P ea + (offset - 4 . a “(OLPSEE: =.4 
| protocol ID | g octets) g : octets) 
Frinn + E atari aa ate + toa sss 555 + 
| split flag | | protocol ID | | protocol ID | 
toss + stan + toss ssa + 
| sequence | | split flag | | flag: FF hex | 
+ number + hoe E + aca i + 
| (2 octets) | | sequence | | padding: OxFF | 
i ra Seo ta + + number + sector fete ter te tg feces + 
| (2 octets) | | padding: OxFF | 
client data PSs SSeS seesasess + oa ee heat cae aa an ear + 
(256 - offset | (protocol ID) | 
- 4 octets) Pee Se SsSserSses F 
| split flag | 
E A AE + toss asa + 
| sequence | 
client data + number + 
(512 - offset | (2 octets) | 
- 4 octets) TESS SSeS seen Sse + 
client data 
(512 - offset 
- 8 octets) 
Pers sesSl SSH ss oS + ac aa aaa rie + 


These packet formats are presented as software would see them 
through ARCNET hardware. [3] refers to this as the "buffer 
format". The actual format of packets on the wire is a little 
different: the destination ID is duplicated, the padding between 
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the offset field and the protocol ID field is not transmitted, and 
there’s some hardware framing information. In addition, the 
hardware transmits special packets for buffer allocation and 
reception acknowledgement which are not described here [3]. 


2.2. Datalink Layer Fragmentation 


ARCNET hardware limits individual frames to 512 octets, which allows 
504 octets of client data. This ARCNET datalink protocol allows the 
datalink layer to break packets into as many as 120 fragments for 
transmission. This allows ARCNET clients to transmit up to 60,480 
octets in each packet. 


The "split flag" describes datalink layer packet fragments. There 
are three cases: an unfragmented packet, the first fragment of a 
fragmented packet, and any other fragment of a fragmented packet. 
Unfragmented packets always have a split flag of zero. 

The first fragment of a fragmented packet has a split flag equal to 
((T-2)*2)+1, where T is the total number of fragments to expect for 


the packet. 


Subsequent fragments of a fragmented packet have a split flag equal 


to ((N-1)*2), where N is the number of this fragment. For example, 
the fourth fragment of a packet will always have the split flag value 
of six ( (4-1)*2 ). 


The receiving station can identify the last fragment of a packet 
because the value of its 8-bit split flag will be one greater than 
the split flag of the first fragment of the packet. 


A previous version of this ARCNET datalink protocol definition 
only allowed packets which could be contained in two fragments. 
In this older standard, the only legal split flags were 0, 1, and 
2. Compatibility with this older standard can be maintained by 
configuring the maximum client data length to 1008 octets. 


No more that 120 fragments are allowed. The highest legal split flag 
value is EE hex. (Notice that the split flag value FF hex is used to 
flag exception packets in what would otherwise be a long packet’s 
split flag field.) 


All fragments of a single packet carry the same sequence number. 
2.3. Datalink Layer Reassembly 


The previous section provides enough information to implement 
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datalink reassembly. To avoid buffer allocation problems during 
reassembly, we recommend allocating enough space for the entire 
reassembled packet when the first fragment arrives. 


Since fragments are sent in order, the reassembly procedure can give 
up on a packet if it receives a fragment out of order. There is one 
exception, however. It is possible for successfully received 
fragments to be retransmitted. Reassembly software should ignore 
repetitious fragments without giving up on the packet. 


Since fragments will be sent briskly, the reassembly procedure can 
give up on a partially reassembled packet if no additional fragments 
for it arrive within a few seconds. 


2.4. Datalink Layer Retransmission 


For each unicast ARCNET packet, the hardware indicates to the sender 
whether or not the receiver acknowledged the packet. To improve 
reliability, datalink implementations are encouraged to retransmit 
unacknowledged packets or packet fragments. Several retransmissions 
may be necessary. Broadcast packets, however, are never acknowledged 
and, therefore, they should never be retransmitted. 


Packets which are successfully received may not be successfully 
acknowledged. Consequently, retransmission by the datalink 
implementation can cause duplicate packets or duplicate fragments. 
Duplicate packets are not a problem for IP or ARP. As mentioned in 
the previous section, ARCNET reassembly support should ignore any 
redundant fragments. 


3. Transmitting IP and ARP Datagrams 
IP and ARP datagrams are carried in the client data area of ARCNET 
packets. Datalink support places each datagram in an appropriate 
size ARCNET frame, fragmenting IP datagrams larger than 504 octets 
into multiple frames as described in the previous section. 


4. IP Address Mappings 


This section explains how each of the three basic 32-bit internet 
address types are mapped to 8-bit ARCNET addresses. 


4.1. Unicast Addresses 
A unicast IP address is mapped to an 8-bit ARCNET address using ARP 


as specified in [2]. A later section covers the specific values 
which should be used in ARP packets sent on ARCNET networks. 
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It is possible to assign IP addresses such that the last eight 
bits are the same as the 8-bit ARCNET address. This would allow 
direct mapping of IP address to ARCNET address without using a 
discovery protocol. Some implementations might provide this as an 
option, but it is not recommended practice. Although such hard- 
wired mapping is initially appealing, experience shows that ARP is 
a much more flexible and convenient approach which has a very 
small cost. 


4.2. Broadcast Addresses 


All IP broadcast addresses must be mapped to the ARCNET broadcast 
address of 0. 


Unlike unicast packets, ARCNET does not attempt to insure delivery 
of broadcast packets, so they may be lost. This will not have a 
major impact on IP since neither IP nor ARP expect all packets to 
be delivered. 


4.3. Multicast Addresses 


Since ARCNET provides no support for multicasts, all IP multicast 
addresses must be mapped to the ARCNET broadcast address of 0. 


5. ARP 


The hardware address length is 1 octet for ARP packets sent over 
ARCNET networks. The ARP hardware type for ARCNET is 7. ARP request 
packets are broadcast by directing them to ARCNET broadcast address, 
which is 0. 


6. RARP 


Reverse Address Resolution Protocol [6] packets can also be 
transmitted over ARCNET. For the purposes of datalink transmission 
and reception, RARP is identical to ARP and can be handled the same 
way. There are a few differences to notice, however, between RARP 
when running over ARCNET, which has a one octet hardware address, and 
Ethernet, which has a six octet hardware address. 


First, there are only 255 different hardware addresses for any given 
ARCNET while there’s an very large number of possible Ethernet 
addresses. Second, ARCNET hardware addresses are more likely to be 
duplicated on different ARCNET networks; Ethernet hardware addresses 
will normally be globally unique. Third, an ARCNET hardware address 
is not as constant as an Ethernet address: ARCNET hardware addresses 
are set by switches, not fixed in ROM as they are on Ethernet. 
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7. Maximum Transmission Unit 


The maximum IP packet length possible using this encapsulation method 
is 60,480 octets. Since this length is impractical, all ARCNET 
implementations on a given ARCNET network will need to agree on a 
smaller value. Therefore, the maximum packet size MUST be 
configurable in implementations of this specification. 


In any case, implementations must be able to send and receive IP 
datagrams up to 576 octets in length, and are strongly encouraged to 
handle IP datagrams up to 1500 octets in length. 


Implementations may accept arriving IP datagrams which are larger 
than their configured maximum transmission unit. They are not 
required to discard such datagrams. 


To minimize the amount of ARCNET fragmentation, implementations may 
want to aim at an optimum IP packet size of 504 bytes. This avoids 
the overhead of datalink fragmentation, but at the expense of 
increasing the number of IP packets which must be handled by each 
node in the path. In addition to encouraging local applications to 
generate smaller packets, an implementation might also use the TCP 
maximum segment size option to indicate a desire for 464 octet TCP 
segments [7], or it might announce an IP MTU of 504 octets through 
an MTU discovery mechanism such as [8]. These would inform non- 
ARCNET nodes of the smaller optimum packet size. 


8. Assigned Numbers 


Datapoint Corporation assigns ARCNET protocol IDs to identify 
different protocols running on the same ARCNET medium. For 
implementations of this specification, Datapoint has assigned 212 
decimal to IP, 213 decimal to ARP, and 214 decimal to RARP. These 
are not the numbers assigned to the IP encapsulation defined by RFC 
1051 [5]. Implementations of RFC 1051 can exist on the same ARCNET 
as implementations of this specification, although the two would not 
be able to communicate with each other. 


The Internet Assigned Numbers Authority (IANA) assigns ARP hardware 
type values. It has assigned ARCNET the ARP hardware type of 7 [9]. 
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Security Considerations 

Security issues are not discussed in this memo. 
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